A hostile VMM can complete a tdvmcall_migtd_receive with
status=VMM_SUCCESS but data_length=0. The previous implementation let
this propagate as Ok(0) through VmcallRaw::recv, which would stall the
caller's read loop indefinitely (no forward progress, no error).

Reject zero-length success inside the receive poll_fn closure with
VmcallRawError::Malformed, which surfaces to upstream callers as a
network error instead of an infinite spin.

Also stop relying on the post-completion data_length on the send path
(per spec, data_length is owned by MigTD when status=0 and is not a
meaningful VMM-reported value after completion). The previously
returned value was already discarded by VmcallRaw::send, so this is a
no-op in behavior but makes the spec contract explicit. Document this
in the poll_vmcall_completion doc comment.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Signed-off-by: Haitao Huang <haitaohuang@microsoft.com>

When the migration context has been destroyed (no entry in
VMCALL_MIG_CONTEXT_FLAGS for the request id), any interrupt injection
from the VMM should be rejected. Previously the else branch discarded
the error with `let _ = ...`, allowing execution to fall through and
treat DMA buffer contents as a valid VMM response.

Return an error immediately so the caller rejects the stale injection.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Signed-off-by: Haitao Huang <haitaohuang@microsoft.com>